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ABSTRACT 



A method for generalized flipping of pixmaps and other 
arrays of image data in a software display device interface 
for computer generated graphics applications. The display 
device interface enables application programs to create 
flipping surface structures representing on and offscreen 
pixmaps, textures, sprites, overlays, etc. The display device 
interface includes a flip function to control the flipping of 
these nipping structures. It also includes functions to syn- 
chronize access to the surfaces represented by the flipping 
structure. Applications and other processes can use these 
access synchronization functions to manipulate surfaces 
represented by the flipping structure without conflicting with 
a client's use of the surface. Clients other than the display 
controller can act as clients of the flipping operation. For 
instance, flipping structures can be used to implement video 
texture mapping, where the client of a texture flipping 
structure is a 3D rendering system. 

23 Claims, 9 Drawing Sheets 
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DISPLAY DEVICE INTERFACE INCLUDING ing images, but can also include mixing audio files to 

SUPPORT FOR GENERALIZED FLIPPING generate sound effects, rendering three dimensional anima- 

OF SURFACES tion using a graphics accelerator, decompressing and playing 

video, and updating the display image fast enough to depict 
This application is related to the following co-pending 5 realistic scenes. 
U.S. patent applications, which are commonly assigned: To control a peripheral devices in this manner, the appli- 
Resource Management For Multimedia Devices In A cation program can attempt to control the peripheral devices 
Computer by Craig G. Eisler and G. Eric Engstrom, directly or can perform operations through a software inter- 
filed on Apr. 25, 1996 as application Ser. No. 08/637, face. A software interface provides access to certain services 
483; 10 through a specified set of operations which can be invoked 
Method And System For Flipping Images In A Window to request the services. For instance, an interface to sound 
Using Overlays by G. Eric Engstrom and Craig G. effect services might include operations to "prepare a sound 
Eisler, filed on Apr. 25, 1996 as application Ser. No. for P lavin g " " start Paying a sound," and "wait until a sound 
08/639,333; bas finished playing." In response to a request for a particu- 

w,t_j*jo t T T\^^ ix- r*-r 15 lar service, the interface attempts to provide the service by 

Method And System In Display Device Interface For . , . . ' . . . , . f , T „ . lL ; 

XJf C J C Xjf u ri I? • C * j taking steps to control the underlying hardware. In effect, the 

Managing .Surface Memory by 0. fine Engstrom and fc ^ ^ ^ application would have to do if it 

£ No 08/641 01* ° D 15 were to try to control the hardware directly. In addition to 

r * °' ' * communicating with the hardware, an interface sometimes 

Multimedia Device Interface For Retrieving And Exploit- 20 provides some resource management so that programs run- 

ing Software And Hardware Capabilities by G. Eric ning in the can snarc access to ^ c hard . 

Engstrom and Craig G. Eisler, filed on Apr. 25, 1996 as ware resources 

application Ser. No. 08/641,017; c # . 1* r 
rr For the vast majority of applications, application pro- 
Method And System For Managing Color Specification gra mmers rely on some form of software interface to interact 
Using Attachable Palettes And Palettes That Refer To 25 ^ the computer » s peripherals. Programmers typically rely 
Other Palettes by Craig G. Eisler and G. Eric Engstrom, oa interfaces to the peripherals so that they can 
filed on Apr. 25, 1996 as application Ser. No. 08/641, focus on the specifics 0 f ^ application rather than on the 
017; and specifics of controlling a particular device. Unfortunately, 
System For Enhancing Device Drivers by Craig G. Eisler ma ny of today's software interfaces cannot provide the level 
and G. Eric Engstrom, filed on Apr. 25, 1996 as 30 of performance that multimedia applications demand, 
application Ser. No. 08/637,530. are a niimber of software products on the market 
These applications are hereby incorporated by reference. today that provide interfaces between application programs 

TECHNICAL HELD aDC * P^P^ 1 ^ devices. These interfaces are sometimes 

35 characterized as low or high level interfaces, and device 

The invention relates to software interfaces for display independent or dependent. A high level interface is one 

devices and more specifically relates to services in a display whose operations request big-picture strategic services, such 

device interface that support flipping of different types of as "start playing this sound" or "display this document." A 

image data including on and offscreen images, overlays, low level interface is one whose operations request tactical 

sprites, texture maps, etc. ^ services specifically, such as "tell the sound card at I/O 

(input/output) address 220 to point its DMA buffer to 

BACKGROUND memory address 1000000" or "tell the video card to copy the 

When creating an application program for a computer ^i pixel ** ion from . a loca i^ artin 3 * addrCSS 

such as a PC, the design of the user interface is a major J* 000001 * a lo ^ on at 1000000 in video memory, 

concern to the application developer. In developing the user 45 In S cneral a m S h [ evcl fterface may be easier for a 

interface, the programmer typically has to include code to Programmer to use, but a low level interface may provide 

capture input from the user and provide output using the better performance and functionality. Ease of use comes 

computer's peripherals. The interaction between an appli- from havm S fewer <* etails T f° ta * e <*» of > while better 

cation and peripheral devices can vary significantly depend- Performance comes from ^ taking advantage of ^special cases 

ing on the type of application and sophistication of the user 50 me ha ^ ware hm6[ ™ weU " Hldin S detaiIs tends t0 du S luse 

interface. In a spreadsheet program, for example, the appli- special cases as well. 

cation needs to be informed when the user has updated a cell The terms "device independent" and "device dependent" 

in a spreadsheet so that it can update the spreadsheet and re f er t0 me extent to which the interface is specific to a 

display the proper result. Since the display changes rather particular piece of hardware. Device independent interfaces 

infrequently and does not contain complex graphics in this ss provide operations that are not specific to a particular brand 

example, the performance of the underlying software and of hardware device. Instead, the operations hide the detail of 

hardware that controls the user interface is less critical. As the hardware from the application and take care of these 

such, the programmer can rely on a high level interface to details internally. In contrast, device dependent interfaces 

graphics and input devices without being particularly con- provide operations to control specific features of a particular 

cerned with the performance of the interface. The user 60 P iccc of hardware. To write an application using a device 

interfaces of many of today's multimedia applications, dependent interface, the application developer has to have a 

however, are significantly more complex and have rigorous detailed understanding of how the specific hardware oper- 

performance requirements. In multimedia games for ates - 

example, the interaction between the application and periph- Hardware dependence is usually not favored because it is 
erals is critical to achieving a highly interactive and realistic 65 not flexible to changes in the underlying hardware and can 
user interface. The interaction between the application can often lead to resource contention problems. Programs writ- 
include not only reading input from a joystick and display- ten for a device dependent interface can be rendered obso- 
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lete by updates to the underlying hardware, and commonly video memory before the application has finished drawing 

do not work for more than one brand of peripheral. In all of the pixels in the display image, 

addition, device dependent interfaces are more susceptible Support for double buffering in today's display controllers 

to resource contention problems because an application has and software interfaces is limited to screen flipping. In the 

access to its state information and can render it inoperable 5 traditional method of screen flipping, only an entire display 

for other applications. image is flipped, and the display device is the client of the 

In general, high level interfaces tend to be device inde- flipping operation. This process is limited because it does 

pendent because they hide details, whereas low. level inter- not support flipping of other types of images such as 

faces tend to be device dependent because they reveal offscreen images, overlays, sprites, texture maps, etc. It is 

details. For instance, "play a sound" does not rely on the i° also limited because the display device is the only client of 

details of any sound card, but "tell the sound card at I/O the flip. Other software or hardware components of the 

address 220 ..." obviously does. system cannot be the consumer of a flip operation. 

While device independent, high level interfaces are gen- To our knowledge, conventional screen flipping does not 

erally easier to use for the reasons explained above, they support flipping of overlays, sprites, or textures. An overlay 

typically are unable to provide the performance and func- 15 is a display surface that is overlayed on top of (or sometimes 

tionality needed for certain types of applications. High level behind) the primary display surface. A sprite is similar to an 

interfaces are often not sufficient for game applications and overlay, and traditionally refers to a display surface that is 

other multimedia applications because they are often inca- blended or composited with the primary surface, 

pable of achieving the desired performance. Games demand A texture map refers to a display surface that is mapped 

higher performance because they must achieve a high degree 20 onto a graphical object. Texture maps are commonly used in 

of user interactivity and visual realism. A game application 3D graphics rendering to represent intricate detail on the 

typically has to collect rapidly changing user input, compute surface of a 3D object. Instead of modelling the surface 

its impact on the current scene, and display the correspond- detail with a complex mesh of polygons, the 3D rendering 

ing images and playback sounds with imperceptible delay. system maps the texture on to the object. 

Because they are designed for specific tasks, peripherals Because of these limitations of conventional screen 
are usually much better at performing certain types of flipping, it is difficult to implement advanced graphics 
functions than the host processor. For example, a video card features. The technique of flipping a surface is useful and 
may have special purpose hardware that can copy pixels sometimes even critical to achieve smooth animation. If an 
much faster than the CPU. A high level interface may not 3Q interface or the underlying hardware does not support flip- 
take advantage of this particular feature or may include ping of overlays or sprites, it is more difficult to achieve 
additional layers of code that consume valuable CPU cycles smooth animation of the overlays or sprites. Similarly, 
and time before the operation is even started on the periph- without support for flipping textures, it is difficult to imple- 
eral. ment advanced features such as video texture mapping 

Since many peripherals have their own computing 35 without unsightly effects. 

resources, such as processors and memory, performance can 

be improved by off-loading some tasks totbe peripheral SUMMARY OF THE INVENTION 
rather than consuming the resources of the host CPU. The invention provides a method and system for support- 
However, without a low level interface to expose these ing generalized flipping of surfaces. Surfaces generally refer 
resources to the application, they are not fully exploited. ^ to arrays of image data including pixmaps, depth (z) buffers, 

One particular operation that is especially important in alpha (transparency/opacity) buffers, and the memory that 
multimedia applications is the process of drawing images for store this data is called surface memory. The generalized 
display. To achieve better performance, it is often necessary flipping method is implemented in a display device 
to manipulate a video card directly. Video cards typically interface, which enables application programs and other 
provide a writable address register that stores a pointer to 45 processes executing in a computer to control a display 
area in the video card's memory holding a screen-sized device. The flipping method is general because it allows for 
display image. In order for an application to control this flipping of any type of surface, in addition to the traditional 
register directly, the application must have specific infor- notion of screen flipping, and it enables clients other than the - 
mation about the card and must keep track of the specific display device to act as the consumer of a flip, 
address location of the display image stored in the video 50 To support generalized flipping, the display device inter- 
card. In addition, the application has to keep track of timing face provides services to create flipping surface structures, to 
information of the display monitor so that it can properly flip a flipping structure, and to synchronize access to surface 
instruct the video card to display an image at a specified memory that the surface structures represent. The display 
location. device interface is a software interface to display hardware 

These hardware related details make it difficult for appli- 55 in a host computer. To create a flippable surface, an appli- 
cations to control double buffering. The term, double cation or other process in the computer invokes the service 
buffering, refers to a technique for generating a display in the display device interface to create a flipping surface 
image. In this well known technique, two different memory structure. This surface structure is capable of representing 
buffers are used to generate an image. While a first image is different types of surfaces including an offscreen pixmap, a 
being rendered to a first buffer, the display hardware scans 60 pixmap that covers less than the entire display screen, a 
out a complete image from a second buffer. To update the texture map, an overlay, an alpha buffer, and a Z buffer, for 
display with a new image, the display hardware then per- example. 

forms a buffer swap. The display image that was just under The flipping service in the display device interface can 

construction is then transferred to the display screen, and a flip a flipping surface structure representing any of these 

new image is constructed in the buffer that held the previous 65 types of surfaces. In response to a request to flip, a flip 

display image. Double buffering is necessary to prevent the fimction exchanges the surface memory currently serving as 

display hardware from displaying the pixels in a region in the front and back buffer. The flip function determines 
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whether and when a flip can be performed. During a flip 
operation, the display device interface controls access to the 
surface memory represented by the flipping structure. 

Producers and clients of the flipping structure can request 
access to the front and back buffers of a flipping structure by 
invoking a service in the display device interface to syn- 
chronize access to a surface. A producer is an application 
program or other process in the computer that is drawing a 
surface to a back buffer in a flipping structure. A client is a 
process in the computer or a hardware device that uses the 
surface in the front buffer to generate a display image or 
perform additional graphics processing. For example, the 
client can be the display controller in the computer or can be 
an application or process running in the computer. An 
example of a client that uses the front surface to perform 
additional graphics processing is a 3D rendering system. 

In one implementation the display device interface pro- 
vides lock and unlock functions that a producer or client of 
a surface can use to access underlying surface memory. 
When a producer or client gets a lock on a surface or part of 
a surface, other producers or clients cannot access that 
surface or part of the surface. The unlock function is used to 
tell the display device interface that the client or producer 
using the surface is finished. 

Generalized flipping as introduced above enables appli- 
cations to perform a variety of graphics rendering operations 
that are difficult or impossible to perform using conventional 
display device interfaces. For example, video texture map- 
ping can be performed using a texture flipping structure. A 
frame of video can be written to the back buffer of the 
texture flipping structure while a 3D graphics rendering 
system reads and maps a frame of video to the surface of a 
graphical object As another example, sprite or overlay 
flipping structures can be used to animate a portion of a 
display image. A variety of other features are possible as 
well. 

Further features and advantages of the invention will 
become apparent with reference to the following detailed 
description and accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a general block diagram of a computer system 
20 in which an embodiment of the invention can be imple- 
mented. 

FIG. 2 is a block diagram illustrating the architecture of 
a device interface in which one embodiment of the invention 
is implemented. 

FIGS. 3A, 3B, 3C, and 3D are block diagrams showing 
four examples of display device architectures. 

FIGS. 4 A and 4B are diagrams illustrating an example of 
a flipping structure with a front and back buffer. 

FIG. 5 is a diagram illustrating an example a general 
flipping structure that shows the relationship between a 
producer and client of the flipping structure. 

FIG. 6 illustrates a specific example of how the flipping 
structure can support video texture mapping. 

FIG. 7 is a block diagram illustrating the object architec- 
ture in one implementation of a display device interface. 

FIG. 8 is a diagram illustrating the refresh period of a 
display device to help illustrate flipping control. 

FIG. 9 is a flow diagram illustrating a method for con- 
trolling a flip operation. 

FIG. 10 is a diagram illustrating method for determining 
whether it is safe to modify a back buffer after a flip request. 
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FIGS. 11 A and 11B are a flow diagram illustrating another 
method for controlling a flip operation. 

DETAILED DESCRIPTION 

5 FIG. 1 is a general block diagram of a computer system 
20 in which an embodiment of the invention can be imple- 
mented. The computer system 20 includes as its basic 
elements a computer 22, one or more input devices 24 and 
one or more output device 26. The computer system can also 
include a communication device 25 and an auxiliary pro- 
cessing device 27. 

Computer 22 generally includes a central processing unit 
(CPU) 28 and a memory system 30 that communicate 

15 through a bus structure 32. CPU 28 includes an arithmetic 
logic unit (ALU) 33 for performing computations, registers 
34 for temporary storage of data and instructions and a 
control unit 36 for controlling the operation of computer 
system 20 in response to instructions from a computer 

20 P ro g ram such as 311 application or an operating system. 
Memory system 30 generally includes high-speed main 
memory 38 in the form of a medium such as random access 
memory (RAM) and read only memory (ROM) semicon- 
ductor devices, and secondary storage 40 in the form of a 

25 medium such as floppy disks, hard disks, tape, CD-ROM, 
etc. or other devices that use optical, magnetic or other 
recording material. Main memory 38 stores programs such 
as a computer's operating system and currently running 
application programs. In some implementations, portions of 

30 main memory 38 may also be used for displaying images 
through a display device. 

Input device 24 and output device 26 are typically periph- 
eral devices connected by bus structure 32 to computer 22. 
Input device 24 may be a keyboard, pointing device, pen, 

35 joystick, head tracking device or other device for providing 
input data to the computer. 

Output device 26 may be a display device, printer, sound 
device or other device for providing output data from the 
computer. 

40 

The communication device 25 can include any of a 
variety of peripheral devices that enable computers to com- 
municate. For example, the communication device can 
include a modem or a network adapter (25). 

4S The auxiliary processing device 27 refers generally to a 
peripheral with a processor for enhancing the performance 
of the computer. One example of an auxiliary processing 
device is a graphics accelerator card. 

It should be understood that FIG. 1 is a block diagram 

50 illustrating the basic elements of a computer system; the 
figure is not intended to illustrate a specific architecture for 
a computer system 20. For example, no particular bus 
structure is shown because various bus structures known in 
the field of computer design may be used to interconnect the 

55 elements of the computer system in a number of ways, as 
desired. CPU 28 may be comprised of a discrete ALU 33, 
registers 34 and control unit 36 or may be a single device in 
which one or more of these parts of the CPU are integrated 
together, such as in a microprocessor. Moreover, the number 

60 and arrangement of the elements of the computer system 
may be varied from what is shown and described in ways 
known in the art. 

The invention may be implemented in any of a number of 
well-known computer systems. For instance, the invention 

65 may be implemented in a personal computer (PC), such as 
IBM-AT compatible computers or computer systems based 
on the 80386, 80486, or Pentium processors from Intel 
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Corporation. Alternatively, the invention may be imple- 
mented on any number of computer workstations, such as 
machines based on a RISC (reduced instruction set 
computing) architecture. The above systems serve as 
examples only and should not be construed as limiting the 
type of computer system in which the invention may be 
implemented. 

FIG. 2 is a block diagram illustrating the architecture of. 
a display device interface 50 in which an embodiment of the 
invention is implemented. This diagram illustrates relation- 
ships between application programs ("applications") 52, the 
display device interface 50, the hardware abstraction layer 
54, and the display hardware 56. Applications 52 access the 
display hardware 56 through the display device interface 50, 
which serves as a device independent interface to the display 
hardware 56. The display device interface 50 performs 
parameter validation, memory management of the video 
memory, and bookkeeping for the interface. We describe 
specific features of the interface in further detail below. 

The HAL (hardware abstraction layer) 54 is a hardware 
dependent interface to the display hardware 56. In this 
embodiment, the HAL includes only hardware specific code. 
It can be an integral part of the display hardware 56, or in 
the alternative, can be implemented in software on the host 
computer (22 in FIG. 1, for example). In the latter case, the 
HAL is typically implemented as a dynamic linked library 
(DLL). The HAL is implemented by and available from the 
manufacturer of the display card or chip. 

The display device 50 interface can optionally include a 
hardware emulation layer (HEL) 58 to emulate display 
hardware features if they are not available in the display 
hardware. 

The display hardware 56 includes the hardware devices 
within and/or coupled to the host computer that are respon- 
sible for displaying visual data including 2D and 3D ren- 
dered graphics and animation, video, text and still images. 

FIGS. 3A, 3B, 3C, and 3D are block diagrams showing 
four examples of display device architectures. FIG. 3A 
illustrates the architecture of a video card 70 which includes 
video memory implemented with DRAM (dynamic random 
access memory) 72. FIG. 3B illustrates the architecture of a 
display card 74 which includes video memory implemented 
with VRAM (video random access memory) 76. The video 
cards shown in FIGS. 3A and 3B represent only two 
examples of video cards with significant on board memory 
in common use today. For example, there are numerous 
types of RAM (random access memory) used on video 
cards. VRAM and DRAM are just two common examples. 
The display device interface 50, shown generally in FIG. 2, 
is designed to be compatible with a wide variety of display 
controllers whether implemented in a video card, in a video 
chip in the computer, or some other configuration. FIG. 3C 
illustrates the architecture of a multimedia card where the 
memory used by the display card is shared with other 
accelerators. FIG. 3D illustrates the architecture of a display 
card where the memory used by the display card is shared 
with the host processor. The display device interface is 
intended to work across any of these architectures, combi- 
nations of them, or other architectures for storing and 
composing pixmaps onto a display device. 

The video card in FIG. 3A includes as its basic elements 
a graphics controller 78, video memory 72 implemented 
with DRAM, and a digital-to-analog converter 80. In this 
type of video card, each of these elements share a common 
bus 82. On one side, the video card is connected to a bus 84 
on the host computer via a bus interface 86. On the other 



side, the video card is connected to a physical display device 
such as a display monitor 88. To generate the video display, 
the video card 70 receives image data and display com- 
mands from the host computer (22, for example) and con- 

5 trols the transfer of image data to a display monitor 88. The 
graphics controller 78 is responsible for acceleration and 
other graphics operations. When the digital-to-analog con- 
verter 80 needs to take the digitally represented image data 
from the DRAM and send it to the monitor, the graphics 

1Q controller 78 is placed on hold until the DAC 80 finishes its 
task. 

The video card 74 in FIG. 3B includes a graphics con- 
troller 90, video memory 76 implemented with VRAM, and 
a DAC 92. One significant difference between the design of 
this card and the card in FIG. 3B is that the graphics 

15 controller 90 and DAC 92 access the VRAM 76 through 
separate ports (94, 96). Coupled to a peripheral bus 98 of the 
host computer via a bus interface 100, the video card 74 
receives image data and commands from its host and con- 
trols the display of image data stored in the video memory 

20 76. Since the VRAM is dual ported, the DAC 92 can transfer 
image data to the monitor 102 as the graphics controller 90 
performs operations on other image data in the video 
memory. 

The video card 1006 in FIG. 3C includes a graphics 

25 controller 1014, "video" memory 1008 (which is not specific 
to any particular technology used to implement the 
memory), and a DAC 1016. One significant difference 
between the design of this card and the card in FIG. 3B is 
that the graphics controller 1014 shares the "video" memory 

30 with other controllers 1010/1012 and the DAC 1016. The 
other controllers 1012 are sometimes used to control other 
peripherals, including I/O devices 1018 such as a mouse, 
track ball, joy stick, or sound card. There are many memory 
architectures for these types of cards and the device display 

35 interface supports all of them. Coupled to a peripheral bus 
1000 of the host computer via a bus interface 1002, the video 
card 1006 receives image data and commands from its host 
and controls the display of image data stored in the 'Video** 
memory 1008. Arbitration between other controllers can be 

40 handled either in the HAL or by the hardware. 

The video card 1056 in FIG. 3D includes a graphics 
controller 1064, "video" memory 1058 (which is not specific 
to any particular technology used to implement the 
memory), and a DAC 1066. One significant difference 

45 between the design of this card and the card in FIG. 3B is 
that the graphics controller 1064 shares the "video" memory 
with the host processor and the DAC 1066. There are many 
memory architectures for these types of cards and the device 
display interface supports all of them. Coupled to a periph- 

50 eral bus 1050 of the host computer via a bus interface 1052, 
the video card 1056 receives image data and commands 
from its host and controls the display of the image data on 
the display monitor 1070. Arbitration between other periph- 
erals on the bus can be handled either in the HAL, by the 

55 video card 1056, by the operating system, or the bus. . 

The display device interface 50 shown in FIG. 2 acts as 
an interface to display hardware such as the video cards (70, 
74, 1006, 1056) illustrated in FIGS. 3A, 3B, 3C and 3D. The 
display device interface 50 enables applications to access 

60 video memory (72, 76, 1008, 1058, for example), including 
both off screen and on screen memory. It also gives the 
applications access to special purpose graphics hardware 
(78, 90, 1014, and 1064, for example), where available, to 
enhance performance. In cases where the underlying graph- 

65 ics hardware does not support a requested service, the 
interface can potentially emulate the service through the 
software in the HEL 58. 
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The display interface supports a generalized flip function. A surface can also be a texture map. A texture map is a two 

The flip function is "general" because it allows applications dimensional image that is mapped to the surface of a 3D 

to flip more that just the screen display, and because a client graphical model. To summarize briefly, the process of tex- 

other than the display device can act as the consumer of the ture mapping involves taking one or more samples from the 

flip. To enable an application to flip images other than the 5 texture map and computing the contribution of these 

display screen, the display interface creates and manages samples on a pixel in a target image. The sampling process 

flippable surfaces. As explained further below, a surface can can ^ as simple ^ taking the ncarest sampkl to a 

represent .an on or offscreen image, a texture, an overlay an d from the t t back intQ the textUfe 

alpha buffer, or a Z buffer, for example On the client side, Alternatively> lhe sam lin rocess can inter polat- 

he chent can include any of a number of display devices in 1Q ^ betweeQ § » map or filtering samples 

the computer system, a 3D graphics rendering system, _r . . L 

another application, the display device driver in the operat- over a 10 * e Asurface can store a texture 

■ svstem etc map in different formats including a MIP (multum m parvo) 

Tne display device interface includes a number of features ma P format * In a MIP mapped texture several versions of an 

that support generalized flipping of surfaces. One feature is W « stored , at dlfferent leve ^ of detaJ \ , u 

a service to aflocate surface memory to hold image data and 15 A P runar y surface ^presents the pixmap image that the 

create a surface structure to manipulate the associated sur- K currently viewing on the display screen. More 

face memory. Another feature is a service that performs a specifically, the primary surface is the surface that the 

flipping operation on a surface structure in response to a display hardware is currently reading, converting to analog 

request from an application. Additional features include values, and displaying on the monitor. In these 

services that synchronize access to surfaces. 20 circumstances, the display device is the client of the surface. 

In allocating memory for a surface, the interface uses Since devices or software other than the display device can 

either the video memory or system memory. In general, the act as the client, the designation of a surface as a primary 

interface attempts to use video memory first, and then uses surface specifies that it is to be used by the display device as 

system memory if the video memory is insufficient. An opposed to other components in the system such as a 3D 

application can also specify that an image is to reside in 25 rendering system or other graphics processing device. The 

system memory or video memory. When we use the term designation as a "primary" surface also differentiates the 

"memory" below, we intend to include either system or surface from an "offscreen" surface, which is not displayed 

video memory. directly but can be used to construct a display image. 

Surfaces In many cases, an image may be constructed from arrays 

In the context of the display device interface shown in 30 of related pixel data stored at different memory locations. 

FIG. 2, a "surface" is an image or an array of alpha or Z For instance, an alpha buffer at one memory region may 

values corresponding to pixels in an image. More store an array of alpha values corresponding to an array of 

specifically, a surface can be an array of pixel values pixel values stored at another memory region. As another 

(pixmap or bitmap), an array of Z values or an array of alpha example, a Z buffer at one memory region may correspond 

values. The surface memory is an area in memory (either 35 to array of pixel values stored at another memory region, 

system or video memory) that holds the this image data. The One embodiment of the display device interface manages 

surface structure is a data structure that defines such things the relationship between associated surface by creating a 

as the size, height, width of the surface as well as what type complex surface structure. The complex structure includes 

of surface the underlying surface memory holds. The surface two or more surfaces inter-related by an attachment link. The 

memory can hold a pixmap, for example, either for display 40 surfaces can be pixmaps, one or more pixmaps and an alpha 

on the screen of the monitor or as an offscreen work area. buffer, one or more pixmaps and a Z buffer, as well as a 

A surface can also represent an alpha buffer or Z buffer. variety of other combinations of surfaces. 

Alpha and Z buffers are just different types of surfaces. An For example, the display device interface can maintain a 

alpha buffer is a surface that comprises an array of alpha pixmap with an associated alpha buffer by creating a com- 

values. Each alpha value describes the degree to which a 45 plex surface structure that represents two surfaces: a surface 

corresponding pixel is transparent. A Z buffer is a surface holding a pixmap, and an attached surface holding the alpha 

that comprises bit depth information used to determine buffer. Surface structures representing the pixmap and alpha 

whether corresponding pixels are visible or are obscured. buffer reference each other via an attachment link. As 

In one implementation of the display interface shown in another example, the display device can maintain a pixmap 

FIG. 2, a surface structure can represent a variety of different 50 with an associated Z buffer. In this case, the complex 

types of images as well as images in different formats. One structure manages two regions of surface memory, one 

typical form of a surface is a pixmap that covers the entire holding the pixmap, and another holding the Z buffer. Like 

display screen of the monitor. This pixmap is sometimes the example above, the two surfaces, surface structures 

referred to as the display image or display screen. In addition representing the pixmap and the Z buffer, reference each 

to representing a display image, a surface can be an overlay 55 other via an attachment link. In one implementation of the 

or a sprite. An overlay and a sprite refer to an image layer interface, one of the structures in a complex surface structure 

that is composited with another image layer. An overlay serves as the root surface. Other surfaces are attached to the 

typically covers less than the entire display screen, but can root surface to form the complex surface. The complex 

be the same size as the display screen in some cases. When structure can then only be destroyed by destroying the root 

overlays are composited with other pixmaps, they typically 60 surface, 

have a depth value or Z order associated with them so that Flipping Surfaces 

the display device interface or underlying hardware can One embodiment of the display device interface uses a 
determine how to composite them. The pixels in an overlay complex surface to support flipping surfaces. Front and back 
may also have associated alpha values that define their buffers are types of surfaces that are used to support double 
transparency. This transparency information is used along 65 buffering or buffering among more than two regions in 
with the depth data or Z order to composite the pixel values memory. The display device interface supports double buff- 
in a source and destination image layer. ering as well as buffering among more than two surfaces by 
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creating a complex surface structure comprising a front the back buffer until the flip (which is asynchronous) is 

buffer and one or more back buffers. The front buffer actually accomplished. In order to set up a flip both the front 

typically holds a completed pixmap that is ready for use by buffer and the back buffer need to be unlocked (and no 

some client of the interface. A back buffer can hold a application is allowed to lock those surfaces during a flip 
completed pixmap that is queued for use by a client, or a 5 ca H)- Once the display device interface has swapped the 

pixmap that is under construction. memory pointers so that the back buffer points at what was 

Surface structures that support double or multiple buff- previously the front buffer in a flipping structure, the display 
ering are designated as flipping structures. This means that ™* daQG do <* no ' let user f access the back buff 1 er 

the front buffer can be swapped or "flipped" with a back ™ tJ * ^termmes ; that whatever device was accessing the 

. a, t * a- • * « • • i * *• front buffer is really done accessing the bits that are now 
buffer. To create a nipping structure in one implementation 10 -^j***..!-!* 

ra. j- i • . r i- * i t • pointed at by the back buffer, 

of the display interface an application invokes a function in ^ Access tQ ^ ^ 

the interface responsible for creating a surface structure and fig. 5 is a diagram of a general flipping structure showing 

designates it as a flipping structure. ^ relatioaship between a producer 170 and client 174 of the 

To support double buffering, for example, the application flipping structure 176. This particular flipping structure 

requests the interface to create a surface structure comprised 15 mc i u d es only a single front and back buffer 178, 180, 

of at least two surfaces, including a front and back buffer. respectively. The front buffer 178 represents a first region of 

FIGS. 4A and 4B are diagrams illustrating an example of a surface memory 182, while the second buffer 180 represents 

flipping structure with a front and back buffer. As shown in a second region of surface memory 184. Additional back 

FIG. 4A, both the front and back buffer structures 150, 152 buffers can be created by chaining back buffer structures to 

refer to corresponding regions of memory: a reference 20 the front buffer. It is also possible to have more than one 

pointer 154 in the front buffer structure refers to region A producer 186 drawing to the back buffer, and more than one 

158, while a reference pointer 156 in the back buffer client 188 accessing the front buffer, 

structure refers to region B 160. The front and back buffer The producer is responsible for drawing a surface to the 

structures are linked to each other with an attachment link back buffer. To accomplish this, it locks the back buffer or 

162. 25 a portion of it, manipulates the surface in the back buffer, 

The display interface includes a flip function that operates and then unlocks the back buffer or at least the portion it was 

on the flipping structure. In response to a single call to this using. 

flip function, the surface structures including the front and The client reads the surface in the front buffer and uses it 

back buffer structures 150 and 152, remain constant from the to generate an image. For example, if the client is the display 

perspective of the application. If the application wishes to 30 controller, it can read a pixmap in the front buffer and 

draw into a surface, it performs its operations on the surface display it. If the client is a 3D rendering system and the 

that it is concerned with and does not have to track the surface in the front buffer is a texture map, the client can 

specific address of the underlying surface memory (158, read the front buffer and map the surface to a 3D graphical 

160) that holds the surface before and after a flip operation. model. 

The flip function controls the details of the flip operation by 35 When the client is accessing the front buffer, it has a lock 

determining when the underlying surface memory can be on at least a portion of the surface memory 182 currently 

swapped and by keeping track of the specific location of the serving as the front buffer. The lock means that other 

underlying surface memory. producers or clients cannot manipulate the portions of the 

To perform a flip on a structure with one front and one front buffer that the client is currently accessing. A client can 

back buffer, the interface swaps or "flips" the reference 40 explicitly request a lock of the front buffer by invoking the 

pointers 150, 152. After the flip, the front buffer reference lock service in the display device interface, 

pointer 156 refers to region B 160 and the back buffer To get direct access to a surface, a client gets a lock to the 

reference pointer 154 refers to region A 158. surface memory holding the surface. The client requests this 

Access Synchronization lock explicitly by invoking the lock function on the surface 

The display device interface includes services to synchro- 45 structure representing the surface memory. For a flip call, the 

nize access to surfaces. One embodiment of the display front buffer is locked during the duration of the call. The 

interface includes a locking service . Locking and unlocking back buffer is locked until the asynchronous flip occurs. This 

are services for controlling access to a surface. For example, is when the client finishes reading the actual surface memory 

in the context of a flipping structure, the locking services can that served as the front buffer before the flip call, 

control a producer's access to a back buffer, on one side, and 50 FIG. 6 illustrates a specific example of how the a flipping 

a client's access to the front buffer on the other side. The structure can support video texture mapping. In this 

producer is typically an application but can generally be any example, there are two flipping structures: one representing 

process running in the host computer of the display device a flipping structure 190 for a texture map; and another 

interface or another piece of hardware. The client, in a representing a flipping structure 192 for a primary surface, 

typical case, is the display controller, but can also be a 55 This particular architecture supports video texture mapping 

application or process executing in the host computer of the where frames in a stream of video are mapped to the surface 

display device interface or another piece of hardware. of a graphical object being rendered by a 3D rendering 

In one specific implementation, the display device inter- system, 

face provides lock and unlock functions to control access to As an overview, the video stream originates from the 

a surface. In addition, operations that access a surface such 60 video source 194, which sequentially writes frames of video 

as a flipping operation or a bit block transfer, implicitly lock to the back buffer 196 of the texture flipping structure. The 

(or prevent access to) the surface or surfaces that they affect 3D rendering system 198 reads the front buffer 200 of the 

until the operations are completed. texture flipping structure 190 to map the current frame of 

The flip operation is an example of this implicit locking video to the surface of a graphical object being rendered, 

of a surface. The display device interface prevents applica- 65 When a complete frame is drawn to the back buffer 196, the 

tions from touching the front buffer during the actual dura- flipping function flips the underlying surface memory 202, 

tion of the flip call. It prevents applications from touching 204 of the front and back buffers 198, 196. 
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The 3D rendering system 198 renders a graphical scene to ducer and the client. In this example, the client always has 

the back buffer 206 of the primary flipping structure 192. a complete frame of video to texture map (display) no matter 

While the 3D rendering system renders the next frame to be how slow (or fast) the video decompression (producer) is 

displayed in the back buffer 204, the display controller 208 creating them. 

scans the current frame in the front buffer (primary surface) 5 The functions in the display device interface described 

210 to the display monitor 210. In this example, the 3D above can implemented in a variety of different ways, 

graphics rendering system 198 is responsible for invoking Elther procedural or object oriented programming 

the flip operation in the display device interface to exchange approaches can be used. In one specific embodiment, surface 
the surface memory 214, 216 of the primary flipping struc- ' sutures and functions relating to them and are imple- 

ture 192 1Q mented using an object oriented approach. 

™ * , • .u u i u * i In this embodiment, the display device interface shown in 

The video source in the above example can be imple- p[G. 2 is implemented as an object that represents the 
mented usmg a vadeo decompressor capable of decompress- underl ^ d £ k device hardware. There can be one 
ing its images to a surface and calling Flip in between of a ^ device object for lo ^ cal dis hy 
frames. An example would be Microsoft's ActiveMovie. device ^ operatioa For example, a software development 
Any 3D application programming interface (API) capable of is environment may have two monitors, one running a game 
reading its texture pixels out of a surface can serve as the us i ng the display device interface shown in FIG. 2, and 
client. An example would be Microsoft's Direct3D or Real- another running the development environment using an 
ity Lab. OpenGL from Silicon Graphics, Inc. can also be alternative display device interface such as GDI (the graph- 
adapted for this particular application. ics device interface), which is part of the Windows® 95 

Video texture mapping is supported using the following 20 operating system from Microsoft Corporation, 

approach. In the following discussion, the references to The display device object in this particular architecture 

"lock" and "unlock" refer to the access synchronization owns all of the global attributes of the display device (e.g. 

functions in one implementation of the display device inter- video card) that it represents. It controls default values for 

face. At initialization, a flipping structure is created that has the global attributes such as the color key values, color 

the capability of being a texture. The video decompressor 25 depth, resolution and the hardware's display mode. As 

(for example ActiveMovie) is pre-initialized with the name explained further below, it also can control a default color 

of a movie file that it is to play back and is then told to table or palette for the primary surface, 

playback the movie into the back buffer of this structure. In this implementation of the display device interface, the 

To begin, the video decompressor plays a single frame. It display device object includes a number of member func- 

does this by locking the back buffer and writing the first 30 dons to create additional objects, which provide services 

frame of the movie into the backbuffer surface memory. It through their respective member functions. These objects 

then calls Unlock to tell the device interface that it is done include a surface object, a palette object, and a clipper 

with the surface and then it calls Flip. Now the front buffer object. 

has a picture in it. A surface object is a specific way to implement the surface 
Tne 3D API has been pre-initialized with all of the 35 structures described above. A surface object, therefore, rep- 
standard information required to create a scene. The 3D API resents a region in memory that holds a pixmap, an alpha 
is now told to texture map the front buffer of the flipping buffer, or a Z buffer, for example. The member functions of 
structure onto the mesh in the scene (for example a ball). The the surface object provides services for managing and 
video decompressor is now told to play the rest of the movie. manipulating surfaces. As explained in further detail below, 
The 3D API calls Lock on the front buffer and reads the 40 these services include functions to flip surfaces, attach or 
pixels out of the front buffer as dictated by its texture detach a surface, perform a bit block transfer, list surfaces 
mapping algorithm (there are well defined algorithms for attached to a given surface, return capabilities of the surface, 
doing this in the industry). When it is done texture mapping return the clipper object attached to the surface, etc. 
the ball, it calls Unlock. A palette object is an object that represents a color table. 

The Video decompressor calls Lock on the back buffer 45 Through a palette object, an application can gain access to 

and starts decompressing the next frame of video. When it and manipulate the color table of the display device. A 

is done making the changes to the back buffer required to palette object allows direct manipulation of the palette table 

create the next frame of video, it calls Unlock. After that it * as a table. This table can have, for example, 16 or 24 bit 

calls Flip to hand the next frame of video to the client (in this RGB entries representing the colors associated with each of 

case the 3D API who is using it for texture mapping). The 50 the indexes or, for 16 color palettes, it can also contain 

Flip call will return an error parameter (saying it is still indexes to another 256 color palette. Entries in these tables 

drawing) if the 3D API has requested and maintains a lock can be retrieved with a get entries member function and 

on the front buffer when the Flip is called. The video changed with set entries member function, 

decompressor can either call the Flip repeatedly or call the In this implementation, a palette object becomes associ- 

Flip function and tell it to wait and retry. 55 ated with a surface object when attached to it. Palette objects 

The Flip call will wait, preventing other applications from can be attached to the pixmap surfaces described above such 

locking the front or back buffers of the flipping structure, as the primary surface, an offscreen surface, a texture map, 

until the 3D API calls Unlock. At this point, after the 3D API arid an overlay. Each of the palette objects attached to these 

has told the device interface that it is done with the front surfaces can be different. 

buffer, the waiting flip command will execute. The memory 60 One embodiment of the display device interface simplifies 
surfaces will be swapped and the next time the client (3D color specification for surfaces by supporting default pal- 
API) calls Lock on the front buffer, it will be accessing the ettes. If a surface object does not have an attached palette, 
next frame of the movie. As soon as the flip call returns the it automatically defaults to the palette of the primary surface, 
video decompressor looks at how much time has passed and In this architecture, the display device object controls the 
decides how many frames to skip (if any) before starting to 65 default palette. 

decompress the next frame of the movie into the backbuffer. The clipper objects represent clip lists. A clipper object 

This is how synchronization is achieved between the pro- can be attached to any surface. In one implementation of the 
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display device interface for a windowing environment, a 
window handle can be attached to a clipper object. Using the 
information provided by the window handle, the display 
device interface can update the clip list of the clipper object 
with the clip list of the window as the clip list for the window 
changes. 

In order to create a surface, palette or clipper object, the 
application first creates an instance of a display device 
object. The application can then create one of these objects 
by invoking one of the display device object's member 
functions to create the object. 

FIG. 7 is a block diagram illustrating the object architec- 
ture in one embodiment. The display device object 300 for 
a display device is the creator and owner of the surface 
objects 302-308 and palette objects 310-312 for that display 
device. It is responsible for managing all of the objects that 
it creates. This ownership relationship is represented by the 
solid arrows 314, 316, 318 from the display device object 
300 to its surface objects 302-308 and palette objects 
310-312. The palette objects 310-312 are attached to asso- 
ciated surface objects via attachment links 320, 322. 

To create a surface object in this architecture, the appli- 
cation calls the display device object's "create surface" 
member function. In response, the CreateSurface member 
function creates a surface object that represents a surface and 
the underlying surface memory that holds it The member 
function creates a surface object with the attributes and 
capabilities specified by the application. If the application 
requests a complex surface (a surface structure including 
more than one surface), then the member function in this 
implementation creates instances of surface objects for each 
surface. 

The application can specify the attributes of the surface 
object by setting fields in a surface description structure that 
it passes to the create surface member function. One imple- 
mentation of this structure and a description of its fields is 
set forth below: 
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-continued 



ddpfPixelFormat is valid. 

ddckCKDestOveriay is valid. 
dddcCKDestBIt is valid. 
ddckCKSrcOverlay is valid. 
ddckCKSrcBlt is valid. 
All input fields are valid 



DDS D_PIXELFORMAT 

DDS D_CKDESTO VERLAY 
DDSD_CKDESTBLX 
DDSD_CKSRCO VERLAY 
DDSD_CKSRCBLT 
DDSD_ALL 
dwHeight 

Height of surface. 

dwWidth; 

Width of input surface. 

1 Pitch 

Distance to start of next line (return value only), 
dw BackBufferCount 

Number of back buffers. 
dwMipMapCount 

Number of mip-map levels. 
dwZBufferBitDepth 

Depth of Z buffer. 
dwAlphaBitDepth 

Depth of alpha buffer. 
dwRescrvcd 

Reserved 

IpSurface 

Pointer to the associated surface memory. 
ddckCKDestOveriay 

Color key for destination overlay use. 
ddckCKDcstBlt 

Color key for destination blit use. 
ddckCKSrcOverlay 

Color key for source overlay use. 
ddckCKSrcBlt 

Color key for source blit use. 
ddpfPixelFormat 

Pixel format description of the surface. 

ddsCaps 

Surface capabilities. 



The surface object maintains a list of its capabilities in a 
surface capabilities structure. As shown in the implementa- 
tion above, this structure is part of the surface description 
structure. One implementation of the surface capabilities 
and a description of its fields follows below: 



typedef struct _J)DSURFACEDESC{ 
DWORD dwSize; 
DWORD dwFlags; 
DWORD dwHeight; 
DWORD dwWidth; 
LONG lPitch; 
union 
{ 

DWORD dwBackBufferCount; 
DWORD dwMipMapCount; 

} 

DWORD dwZBufferBitDepth; 

DWORD dwAlphaBitDepth; 

DWORD dwReserved; 

LPVOID IpSurface; 

DDCOLORKEY ddckCKDestOveriay; 

DDCOLORKEY dddcCKDestBIt; 

DDCOLORKEY ddckCKSrcOverlay; 

DDCOLORKEY ddckCKSrcBlt; 

DDPDCELFORMAT ddpfPixelFormat; 

DDSCAPS ddsCaps; 
} DDSURFACEDESC, FAR* LPDDSURFACEDESC; 
dwSize 

Size of the structure. Initialized prior to use. 

dwFlags 

DDSD_CAPS ddsCaps field is valid. 
DDSD_HEIGHT dwHeight field is valid. 
DDSD_W1DTH dwWidth field is valid. 
DDSD_PrrCH lPitch is valid 

DDSD_BACKB UFFERCOUNT dwBackBufferCount is valid. 
DDSD_ZBUFFERBITDEPTH dwZBufferBitDepth is valid. 
DDSD_j\LP HABITDEPTH dwAlphaBitDepth is valid. 

DDSD_LPSURFACE IpSurface is valid. 



typedef struct __DDSCAPS{ 
DWORD dwCaps; 
} DDSCAPS, FAR* LPDDSCAPS; 
dwCaps 

DDSCAPS_3D 

Indicates that this surface is a front buffer, back buffer, or texture 
map that is being used in conjunction with a 3D rendering system. 

DDSCAPS_ALPHA 

Indicates that this surface contains alpha information. The pixel 
format must be interrogated to determine whether this surface 
contains only alpha information or alpha information interlaced 
with pixel color data (e.g. RGBA or YUVA). 

DDSCAPS_BACKBUFFER 

Indicates that this surface is a backbuffer. It is generally set by the 
create surface function when the DDSCAPS_FLIP capability bit is 
set. It indicates that this surface is THE back buffer of a surface 
flipping structure. DirectDraw supports N surfaces in a surface 
flipping structure. Only the surface that immediately precedes the 
DDSCAPS__FRONTBUFFER has this capability bit set The other 
surfaces are identified as back buffers by the presence of the 
DDSCAPS_FUP capability, their attachment order, and the 
absence of the DDSCAPS_FRONTBUFFER and 
DDSCAPS_BACKBUFFER capabilities. The bit is sent to the 
create surface function when a stand-alone back buffer is being 
created This surface could be attached to a front buffer and/or 
back buffers to form a flipping surface structure after the call to 
the create surface function. 

DDSCAPS_COMPLEX 

Indicates a complex surface structure is being described A 
complex surface structure results in the creation of more than one 
surface. The additional surfaces are attached to the root surface. 
The complex structure can only be destroyed by destroying the 
root 
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DDSCAPS_FLIP 

Indicates that this surface is a part of a surface flipping structure. 
When it is passed to create surface function, the 
DDSCAPS_FRONTBUFFER and DDSCAPS_BACKBUFFER 
bits are not set. They are set by the create surface function on the 
resulting creations. The dwBackBufferCount field in the 
DDS URFACEDESC structure must be set to at least 1 in order for 
the create surface function call to succeed. The 
DDSCAPS_COMPLEX capability must always be set when 
creating multiple surfaces through create surface function. 

DDSCAPS_FRONTBUFFER 

Indicates that this surface is THE front buffer of a surface flipping 
structure. It is generally set by create surface function when the 
DDSCAPS J1JP capability bit is set If this capability is sent to 
the create surface function, then a stand-alone front buffer is 
created. This surface will not have the DDSCAPS_FLIP 
capability. It can be attached to other back buffers to form a 
flipping structure. 

DDSCAPS_HWCODEC 

Indicates surface should be able to have a stream decompressed to 
it by the hardware. 

DDSCAPS_LIVE VIDEO 

Indicates surface should be able to receive live video. 

DDSCAPS__MODEX 

Surface is a 320x200 or 320x240 ModeX surface. 

DDSCAPS_OFFSCREENPLAIN 

Indicates that this surface is any offscreen surface that is not an 
overlay, texture, Z buffer, front buffer, back buffer, or alpha surface. 

DDSCAPS__OWNDC 

Indicates surface will have a DC associated long term. 

DDSCAPS_OVERLAY 

Indicates that this surface is an overlay. It may or may not be 
directly visible depending on whether or not it is currently being 
overlayed onto the primary surface. DDSCAPS_ VISIBLE can 
be used to determine whether or not it is being overlayed at the 
moment. 

DDSCAPS_PALETTE 

Indicates that unique Direct DrawPalettc objects can be created and 
attached to this surface. 

DDSCAPS_PREMARYSURFACE 

Indicates that this surface is the primary surface. The primary 
surface represents what the user is seeing at the moment 

DDSCAPS_PRIMARYSURFACELEFT 

Indicates that this surface is the primary surface for the left eye. 
The primary surface for the left eye represents what the user is 
seeing at the moment with the user's left eye. When this surface 
is created the DDSCAPS_PR I MARYS UR FACE represents what 
the user is seeing with the user's right eye. 

DDSCAPS_SYSTEMMEMORY 

Indicates that this surface memory was allocated in system 
memory. 

DDSCAPS_TEXTURE 

Indicates that this surface can be used as a 3D texture. It docs not 
indicate whether or not the surface is being used for that purpose. 

DDSCAPS_VIDEOMEMORY 

Indicates that this surface exists in video memory. 

DDSCAPS__VISIBLE 

Indicates that changes made to this surface are immediately visible. 
It is always set for the primary surface and is set for overlays while 
they are being overlayed and texture maps while they are being 
textured. 

DDSCAPS_WRITEONLY 

Indicates that only writes are permitted to the surface. Read 
accesses 

from the surface may or may not generate a protection fault, but 
the 

results of a read from this surface will not be meaningful. 
DDSCAPS_ZBUFFER 

Indicates that this surface is the Z buffer. The Z buffer does not 
contain displayable information. Instead; it contains bit depth 
information that is used to determine which pixels are visible and 
which are obscured. 



The create surface function can be used to create a variety 
of different surface structures. One example, as explained 
generally above, is a primary surface. When an application 
requests the interface to create a primary surface in this 
implementation, the interface creates a surface object to 
access the surface memory currently being used to generate 
the display image. This enables the application to access 
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surface memory that is already being used by another 
process in the computer. For example in the context of a 
computer running the Windows Operating System, GDI may 
currently be using this surface memory to control the 
display. To create a primary surface in this example, the 
application fills in the relevant fields of the surface descrip- 
tion structure passed to the interface on the create surface 
function call. 

The application would fill in the fields of the Surface 
description structure as follows: 



DDSURFACEDESC ddsd; 
ddsd.dwSize - sizeof( ddsd ); 
//Tell DDRAW which fields are valid 
ddsd.dwFlags = DDSD_CAPS; 
//Ask for a primary surface 

ddsd.ddsCaps.dwCaps - DDSCAPS_PRIMARYSURFACE; 



Since the surface memory is already being used in the 
system, there is no need to specify the height and width of 
the primary surface. 

As another example, an application can create a plain, 
offscreen surface. An offscreen surface can be used to store 
pixmaps that will be combined with other surfaces in the 
video card, for example. In requesting the interface to create 
this surface, the application might fill in the surface descrip- 
tion structure as follows: 



DDSURFACEDESC ddsd; 
ddsd.dwSize = sizeof( ddsd ); 
//Tell DDRAW which fields are valid 

ddsd.dwFlags - DDSD_CAPS | DDSD_HEIGHT | DDSD_WIDTH; 
//Ask for a simple offscreen surface, sized 100 by 100 pixels 
ddsd.ddsCaps^wCaps = DDSCAPS_OFFSCREENPLAIN; 
dwHeight - 100; 
dw Width = 100; 



In this implementation, the interface attempts to create 
this offscreen surface in video memory, and if there is not 
enough memory, it uses system memory. 

The create surface function can be used to create a 
complex surface structure in a single function call. If the 
DDSCAPS__COMPLEX flag is set in the create surface call, 
one or more "implicit" surfaces will be created by the 
interface in addition to the surface explicitly specified. 
Complex Surfaces are managed as a single surface in this 
implementation. For example, a single call to release a 
complex surface will release all surfaces in the structure, and 
a single call to restore a surface will restore them all. 

One example of a complex surface structure in this 
implementation is a surface structure that includes a Primary 
Surface and one or more back buffers that form a surface 
flipping environment. The fields in the DDSURFACEDESC 
structure, ddsd below, relevant to complex surface creation 
are filled in to describe a flipping surface that has one back 
buffer. 



DDSURFACEDESC ddsd; 
ddsd.dwSize =■ sizeof( ddsd ); 
fi0 //Tell display device interface which fields are valid 

ddsd.dwFlags - DDSD_CAPS | D DSD_J3 ACKB U FFERCO U NT, 
//Ask for a primary surface with a single back buffer 
ddsd.ddsCaps.dwCaps - DDSCAPS_COMPLEX | DDSCAPS_FLIP | 
D DSC APS_PRI MARYS URFACE; 
ddsd. dwBackBufferCount « 1; 



30 
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The statements in the example above construct a double- 
buffered flipping environment. A single call to a flip function 
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in the display device interface exchanges the surface 
memory of the primary surface and the back buffer. If a 
BackBufferCouot of "2" had been specified, two back buff- 
ers would have been created, and each call to the flip 
function would have rotated the surfaces in a circular 
pattern, providing a triple buffered flipping environment. 

The surface object includes a number of member func- 
tions that enable applications to modify or get information 
about attached surfaces. The term, "attached surface," refers 
to a surface in a complex surface structure that is attached to 
one or more other surfaces. 

To attach a surface to another, an application invokes an 
attach surface member function of the surface object. 
Examples of possible attachments include Z buffers, alpha 
channels, and backbuffers. Different types of surfaces can be 
attached to each other; for example, a flippable Z buffer can 
be attached to a regular flippable surface. 

If a non-flippable surface is attached to another non- 
flippable surface of the same type, the two surfaces will 
become a flippable chain. If a non-flippable surface is 
attached to a flippable surface, it becomes part of the 
existing flippable chain. Additional surfaces can be added to 
this chain, and each call of the flip member function will 
cycle one step through the surfaces. 

The surface object also includes a member function to 
detach a surface. If NULL is passed as the surface to be 
detached in this implementation, all attached surfaces will 
be detached. Implicit attachments (those formed by the 
interface, rather than in response to a call to the attach 
surface function) cannot be detached. Detaching surfaces 
from a flippable chain can change other surfaces in the 
chain. If a FRONTBUFFER is detached from a flippable 
chain, the next surface in the chain becomes the FRONT- 
BUFFER and the surface following it becomes the BACK- 
BUFFER. If a BACKBUFFER is detached from a chain, the 
following surface becomes a BACKBUFFER. If a plain 
surface is detached from a chain, the chain simply becomes 
shorter. If a flippable chain only has two surfaces and they 
are detached, the flippable chain is destroyed and both 
surfaces return to their previous designations. 

The surface objects include a member function to retrieve 
an attached surface with specified capabilities. To invoke 
this function, it is called and passed the surface capabilities 
structure with the desired capabilities set. 

If more than one attached surface has the desired 
capabilities, an application can call a member function to 
enumerate the attached surfaces. 

Another member function of the surface object relating to 
attached surfaces is a function that is used to enumerate 
attached surfaces. When invoked by an application, this 
function enumerates each surface attached to a specified 
surface. The function invokes a call back function for each 
attached surface. 

To support double and multiple buffering using surface 
objects, surface objects include a flip member function. This 
function call makes the surface memory associated with a 
back buffer surface become associated with the front buffer 
surface. The surface memory previously associated with the 
front buffer is associated with the back buffer. If there is 
more than one back buffer, then a ring is formed and the 
surface memory buffers cycle one step through this ring 
every time the flip function is invoked. 

While the flip function adjusts the underlying surface 
memory in response to a flip, the surface objects in the 
flipping structure stay constant. For example, in the context 
of double buffering, an application that draws on the back 
buffer always uses the same surface object. The flip function 
switches only the surface memory underneath the surface 
object when a flip operation is requested. 

An application or other program requesting a flip can 
override the default behavior of the flip function by sped- 
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fying the surface structure that will act as the target of a flip. 
In this case, the flip function swaps the surface memory 
underneath the front buffer with the surface memory under- 
neath the specified surface object. 

5 The flip function controls when the exchange of the 
underlying surface memory occurs and ensures that an 
application does not draw to surface memory that is cur- 
rently being used by a client such as a display device. In this 
implementation, the flip function* is synchronized with the 

1Q vertical blank signal. The flip function sets a register in the 
display hardware so that the exchange of the surface 
memory occurs when the display hardware performs a 
vertical retrace. The flip operation is asynchronous so that 
the application can continue processing after it calls the flip 
function. In the interim after the flip call and before the 

15 vertical retrace, the interface write blocks the surface 
memory that previously was associated with the front buffer. 

If the surface memory previously associated with the front 
buffer is still being displayed after an application invokes the 
flip function, the interface does not allow the application to 

20 draw to the new back buffer. This is necessary because the 
new back buffer, in these circumstances, refers to the surface 
memory that is still being used by the display hardware. 
When the interface receives the vertical blank signal, this 
condition is resolved, and the application can now draw to 

25 the back buffer. 

Id the case where an application attempts to draw to a 
surface memory that is not available in these circumstances, 
the flip function returns a value indicating that the display 
device was still drawing to the display monitor. 

30 When an application attempts to invoke the flip function 
on a surface, and the display hardware is in a state that 
makes it unable for the interface to complete the flip, the flip 
function will return an error. In this implementation, the 
application can avoid this response by instructing the flip 

35 function to keep trying until it is successful or some other 
error occurs. To accomplish this, the application calls the flip 
function and sets an additional flag instructing the flip 
function to wait and retry if the hardware is temporarily not 
available. 

The surface object has lock and unlock member functions 

40 that allow a consumer of a surface to directly access surface 
memory. For the purposes of this discussion we assume that 
the consumer of a surface is an application, but it can in 
general refer to a process. To manipulate surface memory, an 
application calls the lock member and specifies the rectangle 

45 on the surface that it wants to access. If the application does 
not specify a rectangle, then the interface assumes that the 
application wants access to the entire rectangle. 

The lock member function fills in the surface description 
structure with the information needed to access the surface 

50 memory. This includes the pitch (or stride) and the pixel 
format of the surface. 

When the application or other process completes its use of 
a surface, it can make the surface accessible by calling the 
unlock member function. 

55 A more detailed description of an implementation of the 
lock and unlock members follows below. 



HRESUUT Lock( 

LPDIRECTDRAWSURFACE lpDDSurfecc, 
60 LPRECT lpDestRcct, 

LPDDSURFACEDESC lpDDSurfaceDesc, 
DWORD dwFlags, 
HANDLE hEvent ) 



65 When the an application or other process calls the lock 
member, it obtains a valid pointer to surface memory 
(lpDDSurface). 



05/16/2003, EAST Version: 1.03.0002 



21 



5,844,569 



22 



The DDSURFACEDESC structure also contains a pointer 
to the surface memory. It is possible to call the lock member 
function multiple times for the same surface object with 
different destination rectangles. The pointer in the DDSUR- 
FACEDESC is used to tie the calls to the lock and unlock 
members together. 

Normally, the lock member will return immediately with 
an error when a lock cannot be obtained because a blit or flip 
is in progress. The DDLOCK_WAIT flag can be used to 
alter this behavior. Instead of returning with an error, the 
lock function will wait until it is safe to access the surface 
memory and then return if the D D LO C K_WAIT flag is set. 

In order to prevent video memory from being video 
memory from being accessed by the graphics controller in 
the display controller during host access to a surface, the 
display device interface holds a lock between lock and 
unlock operations. The display device interface keep track of 
which surfaces are locked or have flips pending on them and 
does not allow those surfaces to be freed until the operations 
are complete on them. To keep track of which surfaces are 
locked, the dipaly interface marks the data structure repre- 
senting the surface object or objects that are locked. The 
display device interface, in this implementation, does not 
allow any surfaces to be freed while the biter or 3D Tenderer 
is active (since it may otherwise degrade performance to 
keep track of the surfaces it is using i.e. src, dest, alpha, z 
etc). 

In an implementation for the Windows® 95 Operating 
System, the lock is the Win 16 lock. The Win 16 lock is the 
critical section used to serialize access to GDI and USER. 
This technique allows direct access to video memory and 
prevents other applications from changing the mode during 
this access. 

Rather than take the Winl6 Lock which prevents the 
hardware from being accessed by stopping GDI from talking 
to it, the display device interface can put GDI in emulation 
mode so that it will not try to talk to the hardware while a 
Lock is taken. These are only two specific implementations 
for the Windows 95 Operating system. Other implementa- 
tions are possible as well. 

The parameters for the lock member function are 
described in further detail below. 



lpDDSurface 

Points to the Surface structure representing the Surface. 
lpDestRect 

Points to a RECT structure identifying the region of Surface that is 

being locked. 
lpDDSurfaceDesc 

Points to a DDSURFACEDESC structure to be filled in with the 

relevant details about the Surface by the lock call. 
dwFlags 

DDLOCK_SURFACEMEMORYPTR 

The default. Set to indicate that Lock should return a valid memory 
pointer to the top of the specified rectangle. If no rectangle is 
specified then a pointer to the top of the surface is returned. 

DDLOCK^EVENT 

Set if an event handle is being passed to the Lock member func- 
tion. 

Lock will trigger the event when it can return the surface memory 
pointer requested. If multiple locks of this type are placed on a 
surface, events will be triggered in FIFO order. 
DDLOCK_WAIT 

Normally, if a lock cannot be obtained because a Bit is in progress, 
a WASSTILLD RAWING error will be returned immediately. If 
this flag is set, however, the lock function will retry until a lock is 
obtained or another error, such as DDERR_SURFACEBUSY, 
occurs. 

hEvent 

Handle to a system event that should be triggered when the surface 
is ready to be locked. 



A consumer of a surface calls the unlock member function 
to notify the interface that the direct surface manipulations 
are complete. 



HRESULT Unlock( 

LPDIRECTDRAWSURFACE IpDDSurfece, 
LP VOID rpSurfaceData) 



The unlock function returns DD_OK if successful, oth- 
erwise it returns one of the following error values: 



DDERR_JNVALIDOBJECT DDERR_INVALIDPARAMS 
DDERR_SURFACELOST DDERR_NOTLOCKED 
DDERR_GENERIC DDERR_INVALIDRECT 
lpDDSurface 

Points to the surface structure representing the surface. 
IpSurfaceData 



20 This is the pointer to the surface memory returned by the 
lock member function in the surface description structure. 
Since it is possible to call the lock function multiple times 
for the same surface with different destination rectangles, 
this pointer is used to tie the lock and unlock function calls 

25 together. 

As set forth above, the display device interface is respon- 
sible for controlling access to surface memory. When an 
application makes a call to modify a surface, for example, 
the display device interface makes sure that it is safe to 
modify the underlying surface memory. For the sake of 

30 clarity, we use the example of an application requesting 
access to a surface, but the same issues arise with respect to 
other producers or clients of a surface structure. In general 
a producer is an entity in the system that is writing to a 
surface, while a client is an entity that is reading from a 

35 surface. When we refer to the display device interface in this 
context, we are referring generally to the display device 
interface and/or the HAL as shown in FIG. 2. 

The method for managing access to a surface can be 
broken into a variety of different cases depending on the 

40 operation being performed and the type of surface structure 
involved. In the case of flipping, the way in which the 
interface manages access to surface memory can be classi- 
fied into two classes: 1) where the flipping structure repre- 
sents an on screen (visible on monitor) surface, and 2) an off 

45 screen surface. 

In the first case, the display interface checks whether an 
application has locked or is biting to the target surface 
memory before trying to process a new flip request. In 
addition, the display interface determines whether the dis- 

5Q play controller has completed a flip already in progress. As 
explained in further detail below, this basically means that 
the display controller has finished reading a display address 
register containing the memory location of the next front 
buffer. While processing a flip request, the display interface 
also prevents bits or locks to the target surface memory 

55 before another flip request is processed. 

Id the second case, the flip control also checks whether an 
application has locked or is biting to the target surface 
memory before trying to process a new flip request. 
However, since a hardware page flip is not involved, the flip 

60 control does not have to ensure that the display controller 
has completed a previous page flip request. 

In the case of a request for a bit, lock, or some other call 
to access a surface, the interface determines whether it is 
safe to access the surface. The interface checks whether a 

65 flip is currently in progress for the surface or surfaces of 
interest, and also checks whether another application has 
locked or is biting to the surface. 
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With the above introduction, we now discuss the case of 
flipping visible surfaces in more detail. Before successfully 
completing a flip, it is sometimes necessary to check 
whether the display controller has completed the last flip to 
avoid generating anomalies (causing tearing) in the display 5 
image. For example, this is necessary when an application 
requests a flip of the front and back buffers in a primary 
flipping structure to ensure that the application does not 
begin writing to a buffer that the display device is still 
reading. It is also necessary when an application attempts to to 
modify surface memory through a bit block transfer or lock 
request before the display controller completes a flip. 

In the case of a primary flipping structure with a front and 
two or more back buffers, it is usually safe to begin drawing 
to one of the back buffers because there is at least one extra 15 
buffer that the application can modify. For instance if there 
are two back buffers, the memory region used as the front 
buffer can be cycled to one back buffer and the application 
can draw to the other back buffer. A conflict can arise, 
however, where the application requests two flips in less 20 
than the refresh time of the monitor. In these circumstances, 
it is still necessary to prevent an application from using the 
surface memory that the display controller is currently 
reading. 

To avoid modifying surface memory that the display 25 
controller is reading, the display device interface (or its 
HAL) checks the state of the display hardware before 
attempting operations that could cause a conflict such as a 
flip, a bit, or a request to lock a surface. In the case of a flip 
operation on a visible flipping structure, it is important to 30 
determine whether it is safe to change the address of the 
surface memory region that is currently serving as the front 
buffer. 

Before describing how the flip operation in more detail, 
we begin by illustrating the behavior of typical display 35 
controller. FIG. 8 illustrates the refresh period of a typical 
display controller. The time line represents the entire refresh 
period 400 of the display. Most display controllers available 
today have a refresh rate of at least 60 Hz and typically are 
at or greater than 72 Hz. The first section of the refresh 40 
period shown in FIG. 8 represents the scan period 402 when 
the monitor scans across horizontal scan lines to display the 
primary surface. The second section represents the vertical 
blank period (VB or VBL) 404. 

In many of the display devices, the display controller 45 
reads the address of the next display image during the 
vertical blank time 404. Once it has read the address, the 
display hardware can then start to display the next display 
image. If the hardware supports page or screen flipping, the 
display device driver (HAL, for example) can change this 50 
address, which in effect, instructs the display controller to 
scan the display image from another region in video 
memory. Unfortunately, most display hardware does not 
specify explicitly when it is safe to draw to a back buffer, or 
in other words, when it has completed a page flip. As such, 55 
the display device interface (in conjunction with the HAL or 
display driver on the host PC) has to determine when it is 
safe to: 1) modify a back buffer in response to a flip, bit, or 
lock request; and 2) in the case of flip request, alter the 
display address. 60 

The display device interface and associated device driver 
(HAL) control access to surface memory after a flip. For the 
purposes of this description we refer explicitly to the driver; 
however, the specific architecture of the interface and driver 
can vary. 65 

FIG. 9 is a flow diagram illustrating one possible example 
of controlling a flip in response to a flip request. The first 
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step 410 represents the flip request of a visible surface 
(overlay, primary, etc.). In response, the driver reads the 
current time from a time resource in the computer (412). 
This time resource can be a hardware or software timer or 
some other common time keeper found in a computer 
system. 

Next, the driver compares the current time with the sum 
of the. time of the last flip request and the refresh time (414). 
If an entire refresh period has not elapsed since the last flip 
request, it is not safe to change the state of the display 
controller. As such, the driver returns a "WasStillDrawing" 
error (416). 

If a refresh period has elapsed since the last flip request, 
the driver records the current time of the flip request and 
proceeds to update the hardware register (418, and 420). 
Specifically, the driver writes the address of the surface 
memory of the new front buffer to the display address. At 
this point, the driver has successfully completed the flip and 
it returns. 

A similar method can be used to determine whether to 
deny a bit or lock request after a flip. FIG. 10 is a flow 
diagram illustrating a similar method to determine whether 
the display device interface should return the "WasStill- 
Drawing" error in response to a bit or lock request. Steps 
430—436 are the same steps as described above for FIG. 9. 
Specifically, the driver checks the current time and deter- 
mines whether a refresh period has elapsed since the last flip. 
If not, the error is returned. Otherwise, the bit or lock 
operation proceeds. 

In addition, or in the alternative to using the time of the 
last flip request, the driver can evaluate whether it is safe to 
complete a flip by determining that the display controller has 
moved from the VB period since the last flip request. If the 
display controller is not in the VB period, but was in it the 
last time, it is safe to change the display address. If the 
display controller is in the VB period, it is not clear whether 
it is safe to complete the flip. In this case, another test such 
as the one illustrated in FIG. 9 can be used to evaluate 
whether to update the display address. 

This particular use of the VBL is just one optimization in 
the flip operation. It can be exploited if the display controller 
provides information about whether it is in the VBL period. 

Another optimization in the flip control is to read the scan 
line register, analyze the scan line position relative to the 
position when the last flip occurred. If the scan line is less 
than the scan line at the time the last flip occurred, then it is 
safe to complete the current flip operation. 

illustrating these optimizations, FIGS. 12A and 12B are a 
flow chart of a specific implementation of the flip control. 
Beginning at the top of FIG. HA, the method begins with a 
flip request (450). In response, the flip control proceeds with 
one or more checks to determine whether it should update 
the display address. The first check is to determine whether 
the display address as changed since the last flip request. The 
flip control reads the display address and determines 
whether it is the same as it was at the last flip request (452). 
If the display address has changed since the last flip request, 
then the display controller has performed a page flip, and it 
is safe to update the display address for the current flip 
request. The flip control method then proceeds as shown in 
FIG. 11B to record current parameters and update the 
display address. 

Another check, shown in dashed lines (454) in FIG. HA, 
is to check whether the hardware explicitly indicates that it 
has completed a page flip. This check is shown in dashed 
lines because it is only available if the display controller 
provides this information. In most display controllers, this 
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information is not available, so the flip control performs As illustrated above, the flip control can perform a variety 

alternative checks using information the display controller of checks to determine when to update the display address, 

does provide, such as whether it is in a vertical blank period In alternative implementations, the type of tests and the 

and the current position of the scan line. In this particular specific manner in which they are performed can vary, 

example, the flip control checks whether a "hardware 5 Though we have explained specific implementations in 

flipped" bit is on (456). If so, it is safe to update the display detailj we do not mtend t0 ]i mi{ tbe of our invention 

address. In these circumstances, the flip control sets the to implementations. 

"hardware flipped" bit and proceeds to the steps shown in „ ,. . t . ... . . . , 

*FIG 11B some display controls, additional processing may be 

T ' ' . c . 4 . .. . . , „ required to ensure that the flip control writes the display 

In the majonty or cases where the display controller does 10 4 a . . .f\ . ... , « . 

>c * L u . . * «. v . lT iU address without conflicting with the display controllers use 

not specify that tt has completed a page flip explicitly, the - . , . „ . . . y 7, . t , . 

flip control has to evaluated state of fhe (feplay confer of da,a - For u,stancc < * da ^ y ,t ?T t- . "1 

in other ways. As introduced, another approach's to check m0 « ,han t on6 "Sf 6 '' u 18 j ) ? ss,ble tbat the ^ C0Dt ^ 1 

u *u *u j- i . ii u X c *u *• i covAti wnte part of a new address in one register as the 

whether the display controller has moved from the vertical ... ; . iL ,. . 

, , . 4fl . * a u * * 4£t\ r display controller reads the display address. In these 

blank period since the last flip request. As shown in step 460, 1 5 . , A , ,. . * « •« , , * 

*t_ a- , i t. i u *u * L j- i * ii • cu-cumstances, the display controller will look to an mcor- 

the flip control checks whether the display controller is ... ■ -j . ♦ .u 

ti • a. ili i if*- ♦ u * * *u \7T> rect address ui video memory to generate the next display 

currently in the vertical blank. If it is not, but was in the VB . a t 4 , . jj tL t iL ,. t r 

■ a *l i * a* * *u •* - r , j * image. In effect, the display address that the display con- 
period on the last flip request (462), then it is safe to update ^,, 0 « j • u* *- * *u • 
iu j. , ij a u .u n* * i * u** trailer actually reads is some combination of the previous 
the display address. As such, the flip control resets a bit , A J . , , , . , , . . . * 4 if _ 
. ,. 4 f ' . . \ r . . , M and current display address, which obviously points to the 
indicating that the display controller was in the VB period 20 r 3 . ' • • «. r, r . 
/^,«\ a j . *u * • i-T^ i-iti wrong memory region. To avoid this problem, the flip 
(464) and proceeds to the steps in FIG. 11B. A 6 . . . • . *, , * . it / 

tc .l * . * . ii • • «l *m * j . *i_ . control can avoid writing the display address during the 

If the display controller is in the VB penod at the current A . ... . . . & . , ; r ,. , , „ 

«■ * »u a- *iu u i • vertical blank period, the penod when the display controller 

flip request, the flip control has to do more checking. First, j iL I f , 4 «_ , a 

•* * .u . * j * * • .l . *u i . ii ■ ■ .u niay read the registers holding the display address. As 

it sets the bit mdicatmg that the display controller is in the ' lA ^ « u > „ 

• j / a£.£\ j £ r u i • *i * *u another alternative, the display controller could set a flag 

VB penod (466) and then performs a check similar to the 25 . . , ,. . r . . . . , . 

i_ • r*r/- a o ii i_ i i. <l. when it has read the display register. This latter approach is 

one shown m FIG. 9. Specifically, it checks whether a . .. . 4l _ . . \ r \ .. . „ T „ JL* . 

- , . . , f . .< * A a . l /A,* similar to the approach in dashed lines m FIG. 12B, where 

refresh penod has elapsed since the last flip request (468, ,. . y , . 4 . 

.-nx rp i- u a.- *u «■ . i » 7u « me display controller sets a bit indicating that it has com- 

470). To accomplish this, the flip control gets the current i t h fl" 

time and compares it with the sum of the last flip request ^ e e a ^ a ^ e ^" 

time plus the refresh time. If a refresh time has elapsed, it is 30 ^ approaches described in connection with FIGS. 9-11 

safe to update the display address. If not, the flip control generally relate to flip requests for visible surfaces. This 

returns the "WasStillDrawing" error. includes the primary surface as well as a visible overlay, for 

Another way to check whether the display controller has example, 

completed a page flip is to evaluate the scan line position at Having described and illustrated the principles of our 

the current time and at the time of the last flip request. This 35 invention with reference to a preferred embodiment and 

method is illustrated in FIG. 11A beginning at step 472. To several alternative embodiments, it should be apparent that 

summarize, this aspect of the flip control compares the value the invention can be modified in arrangement and detail 

for the current scan line with the value of the scan line at the without departing from its principles. Accordingly, we claim 

last flip request (472, 474). If the current value is less than all modifications as may come within the scope and spirit of 

the previous value, then the display controller has completed 40 the following claims, 
a page flip since the last flip request. If the current position 

of the scan fine is below the previous position, then the scan APPENDIX 
line test is inconclusive, and the flip control proceeds with 

the time check starting at step 468. Forming a part of the present specification is the follow- 
When tbe flip control determines that it is safe to update 45 nig: 
the display address, it executes the steps (476—480) shown 

in FIG. UB. In this specific implementation, the flip control Appendix A 
records the current time (476) and scan line (478), and sets 

the display address to the address of the surface memory of (Copyright in the appendix is maintained by Microsoft 

the front buffer. Corporation) 
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APPENDIX A 



Copyright in the following material is retained hy Microsoft 
Corporation of Redmond, Washington. 

5 

The following function descriptions are examples of member functions 
of a surface object in the DirectDraw display device APIs from Microsoft 
Corporation of Redmond, WA 

In this implementation, a surface object includes a number of functions 
10 to perform a bit block transfer ("bit" or "blit"). A description of the bit functions 
follows below. 

HRESULT Blt( 

LPDIRECTDRAWSURFACE lpDDSurface, 
15 LPRECT lpDestRect, 

LPDIRECTDRAWSURFACE lpDDSrcSurface, 
LPRECT IpSrcRect, 
DWORD dwFlags, 
LPDDBLTFX IpDDBltFx) 

20 

The bit member function performs a bit block transfer. This member is 
capable of synchronous or asynchronous blits, either video memory to video memory, 
video memory to system memory, system memory to video memory, or system 
memory to system memory. The blits can be performed using Z information, alpha 
25 information, source color keys and destination color keys. Arbitrary 

stretching/shrinking will be performed if the source and destination rectangles are not 
the same size. 

Normally, bit member function will return immediately with an error if 
the blitter is busy and the blit could not be set up. The DDBLTJVAIT flag can be 
30 used to alter this behavior such that, bit function will wait until the blit can be set up, 
or another error occurs, before returning. 

The bit member function returns DD_OK if successful, otherwise it 
returns one of the following error values: 
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DDERRINVALIDOBJECT 
DDERRGENERIC 
DDERRTNVALIDRECT 
DDERR_NOBLTHW 
5 DDERR_NODDROPSHW 
DDERR_UNSUPPORTED 
DDERRJMORASTEROPHW 
DDERR_NOSTRETCHHW 
DDERRNOZBUFFERHW 

10 

IpDDSurface 

Points to the DirectDrawSurface structure representing the 
DirectDrawSurface. This is the destination of the blit operation. 

15 IpDestRect 

Points to a RECT structure that defines the upper left and lower right points 
of the rectangle on the destination surface to be blitted to. 

lpDDSrcSurface 

20 Points to the DirectDrawSurface structure representing the 

DirectDrawSurface. This is the source for the blit operation. 

IpSrcRect 

Points to a RECT structure that defines the upper left and lower right points 
25 of the rectangle on the source surface to be blitted from. 

dwFlags 

DDBLT_ALPHADEST 
30 Use the alpha information in the pixel format or the alpha channel surface 

attached to the destination surface as the alpha channel for this blit. 

DDBLTALPHADESTCONSTOVERRIDE 

Use the dwConstAlphaDest field in the DDBLTFX structure as the alpha 
3 5 channel for the destination surface for this blit. 

DDBLTALPHADESTNEG 

The NEG suffix indicates that the destination surface becomes more 
transparent as the alpha value increases. (0 is opaque) 

40 

DDBLTALPHADESTSURFACEOVERR1DE 

Use the IpDDSAlphaDest field in the DDBLTFX structure as the alpha 
channel for the destination for this blit 

45 DDBLTALPHAEDGEBLEND 

Use the dwAlphaEdgeBlend field in the DDBLTFX structure as the alpha 
channel for the edges of the image that border the color key colors. 



DDERR_INVALIDP ARAMS 
DDERR_INV ALIDCLIPLI ST 
DDERR_NOALPHAHW 
DDERR_NOCLIPL) ST 
DDERR_SURF ACELO ST 
DDERRNOMIRRORHW 
DDERR_NOROTATIONHW 
DDERR_SURFACEBUSY 
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DDBLTALPHASRC 

Use the alpha information in the pixel format or the alpha channel surface 
attached to the source surface as the alpha channel for this blit. 

5 DDBLTALPHASRCCONSTOVERRIDE 

Use the dwConst AlphaSrc field in the DDBLTFX structure as the alpha 
channel for the source for this blit. 

DDBLT_ALPHASRCNEG 
10 The NEG suffix indicates that the source surface becomes more transparent 

as the alpha value increases. (0 is opaque) 

DDBLTALPHASRCSU RFACEOVERR1DE 

Use the IpDDSAlphaSrc field in the DDBLTFX structure as the alpha channel 
1 5 for the source for this blit. 

DDBLTASYNC 

Do this blit asynchronously through the FIFO in the order received. If there is 
no room in the hardware FIFO fail the call. 

20 

DDBLT_COLORFILL 

Uses the dwFillColor field in the DDBLTFX structure as the RGB color to 
fill the destination rectangle on the destination surface with. 

25 DDBLTJDDFX 

Uses the dwDDFX field in the DDBLTFX structure to specify the effects to 
use for the blit. 

DDBLT_DDROPS 

30 Uses the dwDDROPS field in the DDBLTFX structure to specify the ROPs 

that are not part of the Win32 API. 

DDBLTKEYDEST 

Use the color key associated with the destination surface 

35 

DDBLT KEYDESTOVERRIDE 

Use the dckDestColorkey field in the DDBLTFX structure as the color key 
for the destination surface. ' 

40 DDBLTJCEYSRC 

Use the color key associated with the source surface. 

DDBLTJCEYSRCOVERRTOE 

Use the dckSrcColorkey field in the DDBLTFX structure as the color key for 
45 the source surface. 
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DDBLT_ROP 

Use the dwROP field in the DDBLTFX structure for the raster operation for 
this blit. These ROPs are the same as the ones defined in the Win32 API. 

5 DDBLTROTATIONANGLE 

Use the dwRotationAngle field in the DDBLTFX structure as the angle 
(specified in 1/1 00th of a degree) to rotate the surface. 

DDBLTWAIT 

1 0 Do not return immediately with the DDERR_ W ASSTILLDRAWING 

message if the blitter is busy - wait until the blit can be set up or another 
error occurs. 

DDBLTZBUFFER 

1 5 Z-buffered blit using the Z buffers attached to the source and destination 

surfaces and the dwZBufferOpCode field in the DDBLTFX structure as the 
Z-buffer opcode. 

DDBLTZB UFFERDESTCONSTO VERRIDE 
20 Z-buffered blit using the dwZDestConst field and the dwZBufferOpCode field 

in the DDBLTFX structure as the Z buffer and Z-buffer opcode respectively 
for the destination. 

DDBLTZB UFFERDESTO VERRIDE 
25 Z-buffered blit using the lpDDSDestZBuffer field and the dwZBufferOpCode 

field in the DDBLTFX structure as the Z buffer and Z-buffer opcode 
respectively for the destination. 

DDBLT_ZB UFFERSRCCONSTO VERRIDE 
30 Z-buffered blit using the dwConstSrcZ field and the dwZBufferOpCode field 

in the DDBLTFX structure as the Z buffer and Z-buffer opcode respectively 
for the source. 

DDBLT_ZB UFFERSRCO VERRIDE 
35 Z-buffered blit using the IpDDSSrcZBuffer field and the dwZBufferOpCode 

field in the DDBLTFX structure as the Z buffer and Z-buffer opcode 
respectively for the source. 

lpDDBltFx 

40 

See DDBLTFX structure 

DDBLTFX^ ALPHA 
DDBLTFX JVURRORUPDOWN 
45 DDBLTFX_ROT ATE 1 80 
DDBLTFXROTATE90 



DDBLTFXMIRRORLEFTRIGHT 

DDBLTFXJMOTEARING 

DDBLTFX_ROTATE270 
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HRESULT BltBatch( 

LPDIRECTDRAWSURFACE IpDDDestSurface, 
LPDDBLTBATCH lpDDBltBatch, 
DWORD dwCount, 
5 DWORD dwFIags) 



The bit batch member function performs a sequence of bit function 
operations from several sources to a single destination. 

This function returns DD_OK if successful, otherwise it returns one of 
1 0 the following error values: 





DDERR 


INVALIDOBJECT 


DDERR 


INVAL1DP ARAMS 




DDERR~ 


GENERIC 


DDERR" 


INVALIDCLIPLIST 




DDERR 


INVALIDRECT 


DDERR 


NOALPHAHW 


15 


dderr" 


NOBLTHW 


DDERR 


NOCLIPLIST 




dderr" 


UNSUPPORTED 


DDERR 


SURFACELOST 




dderr" 


NODDROPSHW 


DDERR 


NOMIRRORHW 




dderr" 


_NORASTEROPHW 


DDERR 


NOROTATIONHW 




dderr" 


NOSTRETCHHW 


DDERR, 


_SURFACEBUSY 


20 


dderr 


NOZBUFFERHW 







lpDDDestSurface 

Points to the DirectDrawSurface structure representing the 
DirectDrawSurface. This is the destination of the blit operations. 

25 

lpDDBltBatch 

Points to the first DDBLTBATCH structure defining the parameters for the 
blit operations. 

30 dwCount 

The number of blit operations to be performed. 

dwFIags 

Not currently used. 

35 

HRESULT BltFast( 

LPDIRECTDRAWSURFACE lpDDSurface, 
DWORD dwX, 
DWORD dwY, 
40 LPDIRECTDRAWSURFACE IpDDSrcSurface, 
LPRECT IpSrcRect, 
DWORD dwTrans) 
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*8 

This function performs a source copy blit or transparent blit using a 
source or destination color key. The bltfast member always attempts to perform an 
asynchronous blit if the hardware supports this. It only works on video memory 
surfaces and cannot clip. 
5 Normally, the bit fast member function will return immediately with an 

error if the bliiter is busy and the blit could not be set up. The DDBLTFAST_WAIT 
flag can be used to alter this behavior such that the bit fast member function will wait 
until the blit can be set up, or another error occurs, before returning. 

This function returns DD OK if successful, otherwise it returns one of 
1 0 the following error values : 



DDERR1NVALIDOBJECT DDERRINVALIDP ARAMS 

DDERR GENERIC DDERRSURFACELOST 

DDERR SURF ACEBUSY DDERR INVALIDRECT 

15 DDERREXCEPTION DDERRUNSUPPORTED 
DDERR_NOBLTHW 

IpDDSurface 

Points to the DirectDrawSurface structure representing the 
20 DirectDrawSurface. This is the destination of the blit operation. 

dwX 

X coordinate on destination surface to blit to. 

25 dwY 

Y coordinate on destination surface to blit to. 

lpDDSrcSurface 

Points to the DirectDrawSurface structure representing the 
30 DirectDrawSurface. This is the source for the blit operation. 

IpSrcRect 

Points to a RECT structure that defines the upper left and lower right points 
of the rectangle on the source surface to be blitted from. 



35 



dwTrans 

Specify the type of transfer. 



DDBLTFAST_DESTCOLORKEY 
40 Transparent blit using the destination's color key. 

DDBLTFAST_NOCOLORKEY 

Normal copy blit -- no transparency. 
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DDBLTFAST_SRCCOLORKEY 

Transparent blit using the source's color key. 

5 DDBLTFASTJWAJT 

Do not return immediately with the DDERR WASST1LLDRAWING 
message if the blitter is busy — wait until the blit can be set up or another 
error occurs. 
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We claim: 

1. In a display device application programming interface 
(API) in a computer having a display controller for convert- 
ing a pixmap into a display image on a display screen, a 
computer-implemented method for supporting generalized 
flipping of surface memory, the method comprising: 

in response to an API request to create a flippable surface, 
allocating front and back buffers in video or main 
memory, creating a flipping structure representing the 
front and back buffers, storing memory locations of the 
front and back buffers in the flipping structure, and 
storing surface type in the flipping structure, wherein 
the flipping structure represents an offscreen pixmap, a 
texture map, an overlay, a sprite, an alpha buffer, or a 
Z buffer; 

in response to an API request to lock a region of the front 
buffer or back buffer, determining whether an applica- 
tion or the display controller is currently accessing the 
region, and if not, giving a requesting application 
exclusive access to the region as long as the requesting 
application holds a lock for the region; and 

in response to an API request to flip the flippable surface, 
performing the steps of: 

determining whether any application or the display 
controller is accessing the front or back buffers, and 

when no application is accessing the front or back 
buffer and the display controller is not accessing the 
front or back buffer, flipping the front and back 
buffers and updating the memory locations of the 
front and back buffers stored in the flipping structure 
to reflect new memory locations of the front and 
back buffers. 

2. The method of claim 1 wherein the flippable surface is 
a texture flipping surface, and further including: 

while holding the lock on the back buffer, drawing a first 
texture map to the back buffer; and 

while holding the lock on the front buffer, texture map- 
ping a second texture map in the front buffer to a 3D 
graphical object. 

3. The method of claim 2 further including: 
repetitively making requests to lock the back buffer, and 

while holding each lock corresponding to each lock 
request on the back buffer, drawing a video frame to the 
back buffer; and 
repetitively making requests to lock the front buffer, and 
while holding each lock corresponding to each lock 
request on the front buffer, texture mapping a video 
frame currently stored in the front buffer to a 3D 
graphical object. 

4. The method of claim 1 wherein the flippable surface is 
a texture flipping surface, and further including: 

filling the front buffer with a texture image including 
locking the back buffer, writing the texture image to the 
back buffer, and unlocking the back buffer, wherein the 
step of locking comprises granting an application 
exclusive access to "the back buffer; 

flipping the front and back buffer including checking 
whether any application holds a lock on either the front 
and back buffer, and if not, swapping the front and back 
buffer so that the texture image resides in the front 
buffer; and 

performing a texture mapping operation including locking 
the back buffer, texture mapping the texture image to a 
surface of a graphical object, and after the texture 
mapping step is complete, unlocking the front buffer. 
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5. The method of claim 1 wherein the flippable surface 
represents first and second alpha buffers, and the front and 
back buffers each store an array of alpha data. 

6. The method of claim 1 wherein the flippable surface 
represents first and second z buffers, and the front and back 
buffers each store an array of depth data. 

7. The method of claim 1 further including: 

in response to a bit block transfer (bit) API request to copy 
a block of pixels to a destination in the front or back 
buffer, checking whether an application currently has a 
lock or is already performing a bit block transfer to the 
destination, and if so, denying the request. 

8. The method of claim 1 further including: 

in response to a bit block transfer API request to copy a 
block of pixels to a destination region in the front or 
back buffer, checking whether an application currently 
has a pending flip request on the destination region or 
whether another bit block transfer to or from the 
destination region is in progress, and if so, waiting until 
the pending flip request is completed for the destination 
region or the bit block transfer in progress is completed 
to carry out the bit block transfer API request. 

9. The method of claim 1 wherein the step of determining 
whether an application or the display controller is currently 
accessing the region includes determining whether any 
application holds a lock to the region, determining whether 
a bit block transfer to or from the region is in progress, and 
determining whether a flip operation is in progress on the 
front or back buffers. 

10. The method of claim 1 wherein a pixmap in the front 
buffer is converted to a display image and displayed on a 
display monitor by a display controller and wherein the steps 
performed in response to the API request to flip the front and 
back buffers include: 

determining whether a previous request to flip the front 
and back buffers is complete. 

11. The method of claim 10 further including: 
determining whether a refresh period of the display con- 
troller has elapsed since the previous flip request. 

12. The method of claim 11 further including: 
reading a current position of the scan line and determining 

whether the current position of the scan line is less than 
a position of the scan line at the time of the previous flip 
request. 

13. The method of claim 11 further including: 
determining whether the display controller has moved 

from a vertical blank period since the previous flip 
request. 

14. In a computer having a display controller for convert- 
ing a pixmap into a display image on a display screen, a 
computer implemented method for controlling flipping com- 
prising: 

in response to a request to flip a front buffer and a back 
buffer, evaluating whether to instruct the display con- 
troller to flip the front and back buffer including: 
determining whether a refresh period of the display 

controller has elapsed since a previous flip request; 

and 

reading a current position of the scan line and deter- 
mining whether the current position of the scan line 
is less than a position of the scan line at the time of 
the previous flip request; 

if, based on the evaluating step, the display controller 
has completed a flip since the last flip request, then 
instructing the display controller to flip the front and 
back buffer. 
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15. The method of claim 14 further including: 

at successive flip requests, recording whether the display 
controller is in a vertical blank period; and 

evaluating whether to instruct the display controller to flip 
the front and back buffer by determining whether the 
display controller has moved from the vertical blank 
period since the previous flip request. 

16. The method of claim 14 wherein the step of instructing 
the display controller to flip the front and back buffer 
comprises writing an address of the back buffer into a 
display register of the display controller such that the back 
buffer becomes the front buffer in the next refresh period. 

17. The method of claim 16 wherein the evaluating step 
includes reading the display register to determine whether a 
display address has changed since the previous flip request. 

18. A computer readable medium on which is stored an 
application programming interface (API) for controlling 
acces to a display controller, said API comprising 
instructions, which when executed by the computer, perform 
the steps of: 

in response to an API request to create a flippable surface, 
allocating front and back buffers in video or main 
memory, creating a flipping structure representing the 
front and back buffers, storing memory locations of the 
front and back buffers in the flipping structure, and 
storing surface type in the flipping structure, wherein 
the flipping structure represents an offscreen pixmap, a 
texture map, an overlay, a sprite, an alpha buffer, or a 
Z buffer; 

in response to an API request to lock a region of the front 
buffer or back buffer, determining whether an applica- 
tion or the display controller is currently accessing the 
region, and if not, giving a requesting application 
exclusive access to the region as long as the requesting 
application holds a lock for the region; and 

in response to an API request to flip the flippable surface, 
performing the steps of: 

determining whether any application or the display 
controller is accessing the front or back buffers, and 

when no application is accessing the front or back 
buffer and the display controller is not accessing the 
front or back buffer, flipping the front and back 
buffers and updating the memory locations of the 
front and back buffers stored in the flipping structure 
to reflect new memory locations of the front and 
back buffers. 

19. A display device application programming interface 
implemented in a computer system including a processor, 
system memory, a display controller, and video memory, the 
display device API comprising: 

an interface function operable to create an instance of a 

display object in response to a create display object call 

from an application executing in the computer system, 
the display object including a create surface member 

function operable to create an instance of a flippable 

surface object representing a flippable surface of a type 

selected from the group consisting of: 

an offscreen pixmap, 

a texture map, 

an overlay, 

an alpha buffer, and 

a Z buffer; 

wherein each instance of the flippable surface object 
includes reference pointers to locations in video or 
system memory where corresponding flippable sur- 
faces are stored, and includes data identifying the 
type of the flippable surface; and 
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wherein the surface object includes a flip member 
function operable to control flipping of each instance 
of the flippable surface object, and lock and unlock 
member functions operable to synchronize access of 
one or more applications to the locations in video or 
system memory where the corresponding flippable 
surfaces are stored. 

20. In a display device interface for a display controller 
that converts a primary surface into a display screen on a 
display monitor, a computer-implemented method for sup- 
porting generalized flipping of surface memory, the method 
comprising: 

in response to a request to create a primary flipping 
surface, creating a primary flipping surface structure; 

in the primary surface structure, storing a front buffer 
reference to a front buffer that holds a pixmap being 
displayed on the display screen, and storing a back 
buffer reference to a back buffer that holds pixmap to 
be displayed on the display screen; 

in response to a request to create a second flipping 
surface, creating a second flipping structure; 

in the second flipping surface structure, storing a front 
buffer reference to a front buffer for storing a first array 
of pixel data, and storing a back buffer reference to a 
back buffer for constructing a second array of pixel 
data, wherein the first and second arrays of pixel data 
are of a type selected from the group consisting of: 
an offscreen pixmap, 
a sprite, 
a texture map, 
an overlay, 
an alpha buffer, and 
a Z buffer; 

in response to a request to flip the primary flipping 
structure by an application, determining whether 
another application is currently accessing the front or 
back buffers corresponding to the primary flipping 
structure, determining whether the display controller 
has completed a previous flip request, and if no other 
application is accessing the front or back buffers and 
the display controller has completed a previous flip 

' request, then writing an address of the back buffer to 
the display controller, and updating the front and 
back buffer references in the primary flipping struc- 
ture; 

in response to a request to flip the second flipping 
structure from an application, determining whether 
another application is currently accessing the front or 
back buffers corresponding to the second flipping 
structure, and if not, updating the front and back 
buffer references in the second flipping structure; 

in response to requests from applications to access the 
front or back buffer of the primary flipping structure, 
synchronizing access to the back buffer of the pri- 
mary flipping structure; and 

in response to requests from applications to access the 
front or back buffer of the second flipping structure, 
synchronizing access to the front buffer and back 
buffer of the second flipping structure. 

21. The method of claim 20 wherein the second flipping 
surface structure is a texture flipping structure, and further 
including: 

in response to a lock request for the back buffer of the 
texture flipping structure from an application, granting 
the application exclusive access to the back buffer of 
the texture flipping structure as long as the application 
holds a lock on the back buffer; 
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in response to an unlock request for the back buffer of the 
texture flipping structure from the application, freeing 
access to the back buffer of the texture flipping struc- 
ture; 

in response to a lock request for the front buffer of the 
texture flipping structure from a 3D rendering system, 
granting the 3D rendering system exclusive access to 
the front buffer of the texture flipping structure; 
in response to an unlock request for the front buffer of the 
texture flipping structure from the 3D rendering 
system, freeing access to the front buffer of the texture 
flipping structure; and 
in response to a request to flip the front and back buffers 
in the texture flipping structure, checking whether any 
client has a lock on either the front or back buffers of 
the texture flipping structure, and if not, swapping the 
front and back buffers of the texture flipping structure. 
22. In a display device interface for a display device 
controller that converts a primary surface into a display 
screen on a display monitor, a computer-implemented 
method for supporting generalized flipping of surface 
memory, the method comprising: 

receiving a call from an application to create a flipping 
structure, wherein the application designates any of the 
types of surfaces selected from the group consisting of: 
an offscreen pixmap, 

a pixmap that covers less than the entire display screen, 

a texture map, 
an overlay, 
an alpha buffer, and 
a Z buffer; 

in response to the call to create the flipping structure, 
creating a flipping structure including a front buffer 
for storing a first array of pixel data for use by a 
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client other than the display device, and a back buffer 
for constructing a second array of pixel data; 
synchronizing access to the back buffer; and 
in response to a request to flip the flipping structure 
5 from an application, flipping the front and back 

buffer. 

23. The method of claim 22 wherein the flipping surface 
structure is a texture flipping structure, and further includ- 
ing: 
10 & 

in response to a lock request for the back buffer of the 
texture flipping structure from an application, granting 
the application exclusive access to the back buffer of 
the texture flipping structure as long as the application 
is holds a lock on the back buffer; 

in response to an unlock request for the back buffer of the 
texture flipping structure from the application, freeing 
access to the back buffer of the texture flipping struc- 
ture; 

20 in response to a lock request for the front buffer of the 
texture flipping structure from a 3D rendering system, 
granting the 3D rendering system exclusive access to 
the front buffer of the texture flipping structure; 

25 in response to an unlock request for the front buffer of the 
texture flipping structure from the 3D rendering 
system, freeing access to the front buffer of the texture 
flipping structure; and 
in response to a request to flip the front and back buffers 

30 in the texture flipping structure, checking whether any 
client has a lock on either the front or back buffers of 
the texture flipping structure, and if not, swapping the 
front and back buffers of the texture flipping structure. 

* * * * * 
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